Columbia Kermit/kermit.zip/newsgroups/misc.19950726-19950929/[e-mail]_Tue Sep 5 17:57:25 1995.msg

Internet Message Format | 2020-01-01 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA01407
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Tue, 5 Sep 1995 15:28:40 -0400
Received: by apakabar.cc.columbia.edu id AA21697
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Tue, 5 Sep 1995 15:28:38 -0400
Path: news.columbia.edu!sol.ctr.columbia.edu!news.moneng.mei.com!news.ecn.bgu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!newsfeed.internetmci.com!news.mathworks.com!news4.ner.bbnplanet.net!news3.near.net!sun3.ipswitch.com!ddl
From: [e-mail] (Dan Lanciani)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: MS-KERMIT 3.14 hanging on idle TCP/IP connection?
Message-Id: <[e-mail]>
Date: 5 Sep 95 17:57:25 GMT
References: <42d2u9$[e-mail]> <[e-mail]> <[e-mail]>
Organization: Internet
Lines: 63
Apparently-To: [e-mail]

In article <[e-mail]>, [e-mail] (Joe Doupnik) writes:
|
|     Supplementing Dan's decent advice...
|
| In article <[e-mail]>, [e-mail] (Dan Lanciani) writes:
| > In article <42dodl$[e-mail]>, [e-mail] (Seth Chaiklin) writes:

|     True, but MSK does answer ARPs all the time the TCP stack is
| active (while there is a session going). MSK does regular ARP caching
| too, but it does not timeout the entries for the currently used remote
| hosts. The bug seems to be in Linux.

I'd say that the limited information so far provided points to hardware/
drivers or kermit more than Linux, but at this point anything is possible.
(This is based on no internal knowledge of kermit or Linux but on the general
understanding that some kinds of ARP bugs are much more likely to be noticed
than others.)

| > Start kermit fresh and don't connect to anything (I assume you can do this
| > and still have the tcp running?).  Now try to ping kermit from a machine
| > which has no ARP entry for kermit.  If this works and the first test failed
|
|     This won't work as intended because MSK does not run its TCP/IP stack
| until a session has started (or is starting). After all, why run a TCP/IP
| stack if it's not being used?

Well, I think we just demonstrated one reason. :)

I suggest then that you modify the test to start kermit fresh with one
connection to a random machine and do the ping as soon as possible
from another machine.  Of course, this is only interersting if the
first test failed, so maybe you don't need to do it at all.  The idea
was just to try to determine whether the hardware (or kermit image)
was becoming corrupt over time.

|     Something else to keep in mind is another station coming on the
| air with MSK's IP number. That clobbers ARP caches.

This can't be happening in the case in question since it would result
in an incorrect ARP entry on the Linux machine (as opposed to the lack
of any entry as observed).

|MSK 3.14 checks for
| another station using it's IP address when the TCP/IP stack is started.
| (It ARPs for its own IP number and declares any response an imposter. I
| had to insert an special case to work around echoing by NDIS drivers.)

Wouldn't it be funny if that special case was somehow accidentally filtering
out the ARP request from Linux?  I wonder if there is anything unusual (but
legal) about Linux ARP requests?  A network trace of this problem would
make diagnosis _so_ much easier...

|     There are still some rather unusual (eg, wierd) situations where ARP
| responses simply don't get through. I don't know why, but they don't. One

Is this in general or something specific to kermit?

| always suspects one piece of code or another and probably one does have a
| problem, but the saying "it does not happen here" applies to make diagnosis
| difficult.

                Dan Lanciani
                ddl@harvard.*